1. Field of the Invention
The present invention relates to the field of lighting control systems typically used in buildings. More particularly, the present invention relates to the field of centralized building lighting control systems for managing, controlling and maintaining lighting within and around a building.
2. Description of Related Art
Centralized building lighting control systems have conventionally been configured with a head-end central control panel. Output devices such as relay panels are connected via a multi-wire communication signal line to the head-end central control panel. Input devices such as switches are connected by either the same communication signal line or a separate communication line. FIGS. 1 and 2 depict both of these scenarios. In order to communicate with the head end controller, the input and output devices are addressed locally with either dip switches or selector switches as, for example, depicted in FIG. 3. Each device on the communication signal line must have a unique address. If a device is mistakenly addressed to another device's address it will cause errors on that communication signal line. Consequently, installers must keep track of what addresses have been assigned during the installation of the devices. As can be appreciated, this is a cumbersome and time consuming task.
Centralized lighting control systems have traditionally been controlled by a head-end controller. This controller is typically configured with a central processor that manages all of the devices on the communication signal lines. Because of this arrangement, a limited number of communication lines are able to be connected to the control system, thus limiting the number of input and output devices able to be controlled. Coordination and control of the entire system is accomplished in the head-end controller. Additionally, modifications to the control scheme need to be down loaded from a separate desktop or laptop computer. This computer is connected to the head end controller either directly or through an interface module as, for example, depicted in FIG. 4. This computer is fitted with a software package that is able to modify the central controller's input/output scheme or control sequence (i.e. to program the system). To make these modifications, the user connects the computer to the head end controller with either a serial connection (RS-232) or an Ethernet connection. The user then makes the appropriate modifications on the connected computer utilizing the software package residing on that computer. After the modifications are complete on the connected computer, they are downloaded to the head end controller. The computer is solely used for programming and/or monitoring the head end controller.
The traditional head end based control systems have several limitations including, for example, the following.
Head end control based systems, due to their architecture, have a limited number of inputs (i.e. switches) and outputs (relays). Although large scale control systems exist which are capable of handling a large number of inputs and outputs, those systems are suited for just that purpose—large scale control. They are typically relatively expensive and practically useable only for large scale control systems/applications. The head end control based systems are also typically very expensive and, although capable of controlling a relatively small input/output count system, they are generally cost “in-effective” for both small and large scale applications.
Head end control based systems do not effectively interface with the individual programming the system. Since the “programming” computer is not an integral part of the lighting control system, it requires the user (programmer) to develop the program and down load it to the head-end controller. At first glance, this may appear to be a benefit since the computer is not “required” for the system to function. But after further analysis it quickly becomes evident that it is not a benefit, but rather a hindrance. With the traditional head end based system a computer is still required for download of the program; it is simply not used for direct interaction or control of the system. The user can program, monitor and even manipulate the system but this is done through downloads and uploads from the head end controller that is the means of control for the system. FIG. 5 depicts the flow of communication for typical head end based systems.
It is noted that head end based systems exist that do not require a computer to program them. In this type of setup all of the information is stored and programmed directly on a keypad on the head end controller. These types of systems are worse yet, as they do not have the means to store the program on a separate device (i.e. computer's hard drive). Should the head end controller fail, the program is lost and must be “rebuilt” in a new head end controller.
As depicted in FIG. 3, traditional head-end based systems use a method of addressing devices on the network with dip switches or selector switches. This requires all of the devices connected to the system to be addressed prior to its installation. All devices need to be coordinated such that no two devices on a communication link share the same address. This may not seem like a monumental item at first, but after further examination this can be a daunting task. First of all, devices have to be mapped and coordinated prior to the installation. Devices on different communication links can share the same address with a device on another communication link. If a device is accidentally installed on the wrong communication link, duplication of addresses can exist. Secondly, good records of the system and how it is all connected must be maintained with this type of system. If the system is initially set up and at a later date modifications to the system are made, the records from the first installation must be coordinated with the modification to assure that no duplication of addressing is done on a communication link. However, as a practical matter, records can be lost or inaccurate leading to difficulties when making future modifications.
In head end control based systems, a paper directory card must be maintained and amended at the relay or dimming panels as the controlling loads are added and/or changed. This directory is used to describe what area or lighting circuit is controlled by a given relay or dimmer. Many times this paper card is lost, not maintained and/or contains incorrect entries. When an addition or modification is required, the installer must, therefore, trace out all of the unknown circuits and map out the wiring prior to the modification or addition. Additionally, when a relay or dimmer has failed or is not operating as intended, it can be difficult to rectify the problem without an accurate record of the circuitry. As a consequence, modifications and troubleshooting can be relatively time consuming and costly.
To conserve energy, modern facilities lighting control systems have incorporated occupancy sensors and ambient light level sensors. Occupancy sensors are used to detect motion in a given area. When motion is detected, a digital “on” signal is sent back to the head end controller to turn on a relay or dimmer. The occupancy sensor also starts an internal timer and, when the time cycle is completed, sends a digital “off” signal back to the same head end controller. The timer is continually reset by the motion sensor, thus maintaining the lights on as long as motion is detected. The deficiency with this type of control system is that all of the control settings are at the sensor. Should a different delay/cycle time be desired, it must physically be set at the sensing device/sensor. These devices are typically mounted to the ceiling of the controlled area and, in larger systems, there can be hundreds or thousands of them throughout the facility. Making a change to the delay/cycle time (a task frequently required to “calibrate” the system) can, therefore, take a substantial amount of time and be fairly costly.
The other component used in energy conservation of a lighting control system, the ambient light sensor, is typically a separate device with manual control of the set points. The user simply “picks” an event to occur (on or off of a lighting relay or level of a dimmer) based on the light level in the area. This can be cumbersome as the sensors are not self calibrating to the area of control and require the installer to manually set, and often reset them, until the desired set point is attained. Like the occupancy sensor, all levels of control and setpoints are at the device. Any adjustments and/or setting of the time delay, sensitivity to light, and set points in connection with both time and light must be made manually at the device. Similarly, adjusting, maintaining and repairing these devices can be relatively time consuming and costly.